Amazon File CacheでAmazon EFSのキャッシュが可能か確認してみた
しばたです。
前回は新サービスであるAmazon File Cacheの概要を解説しました。
この記事のなかで
要はS3バケット or NFS v3のNFSサーバーといった感じなのですが、Amazon EFSがサポート対象かは明記されていませんでした。
(EFSについては実際に環境を作って動作確認するしかなさそうです...)
とお伝えしたので実際に試してみることにしました。
Amazon EFSの特徴と懸念点
Amazon EFS (EFS)はAWSが提供するマネージドなNFSサーバーであり、単純なNFSサーバーでなく多くの独自機能を持っています。
Amazon File Cacheとの連携を考える上で一番問題になりそうなのはEFSはNFS v4(v4.0, v4.1)のサーバーである点です。
Amazon File Cacheがキャッシュ元サーバーへNFS v3でしか通信できないのであればそもそも駄目でしょう。
そしてNFS v3とv4で完全互換というわけでも無いのでその辺の不安もあります。
ちなみにEFSファイルシステムをマウントする際に敢えてNSF v3を明示して通信させると処理がハングします。
個人的には既に嫌な予感がしています...
NFSのバージョン以外だとIntelligent-Tieringといったストレージクラスの移行機能もキャッシュとの相性は悪そうです。
確認
ここから実際に試していきます。
今回は前回と同じVPC環境にEFS環境を作成しAmazon File Cacheのキャッシュ元にします。
接続確認用EC2は前回のものをそのまま流用します。
EFSの準備
EFSはざっと以下の設定で新規作成してます。
- ストレージクラス : 標準
- ライフサイクル管理 : なし
- パフォーマンスモード : 汎用
- スループットモード : バースト
- ネットワーク構成 : 2AZのPrivateサブネットに配置
- セキュリティグループはNFSのポート(TCP 2049, UDP 2049)を解放
- 追加のポリシー指定は無し
出来上がりはこんな感じになってます。
DNS名に関しては以下のIPを返しています。
$ dig fs-07aexxxxxxxxxxxxx.efs.ap-northeast-1.amazonaws.com +short
10.0.21.13
EC2の準備
次にEC2は前回のUbuntu 22.04環境にEFSへのアクセス用にnfs-common
を追加インストールしています。
# Lustre Clientは既にインストール済み
# /sbin/mount.nfs をインストール
sudo apt install nfs-common -y
テストデータ投入
EC2から確認用のテストデータを追加しておきます。
今回はEFSマウントヘルパーは使わず/mnt/efs
にマウントしてテストデータ(hello-efs.txt
)を登録しておきます。
# マウトポイント作成
sudo mkdir /mnt/efs
# 今回はマウントヘルパーは使わず書き込み可能でマウント
sudo mount -t nfs4 -o rw,nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-07aexxxxxxxxxxxxx.efs.ap-northeast-1.amazonaws.com:/ /mnt/efs
# テストファイルを追加
echo "Hello EFS!" > /mnt/efs/hello-efs.txt
結果はこんな感じで登録されます。
これでEFSへの疎通自体が出来ることも確認できました。
# 作成したファイルの中身を確認
$ cat /mnt/efs/hello-efs.txt
Hello EFS!
一応念のため最後にアンマウントしておきます。
# アンマウント
sudo umount /mnt/efs
Amazon File Cacheの構築
これで事前準備が終わったのでAmazon File Cacheの構築を開始していきます。
前回のキャッシュは既に削除済みで、新しくキャッシュを作りなおします。
キャッシュ元設定を前回から変えてNFSにし、Data repository pathにEFSのDNS名を割り当てます。
名前解決が必要なのでDNSサーバーの指定をVPCのDNS(Route 53 Resolver)のIPにしておき、その他設定は適当です。
- Path : EFSのDNS名 (nfs://fs-07aexxxxxxxxxxxxx.efs.ap-northeast-1.amazonaws.com)
- DNS : Route 53 ResolverのIP (10.0.0.2)
- Cache path : 任意の値 (/efs)
入力内容の確認を経てキャッシュを作成します。
特にエラー無く作成が開始されました。
10分ほど待つとステータスが「利用可能」に変わりました。
これで無事作成できた様に見えたのですが、データリポジトリの関連付けが「作成」から変わらない状態になってしまいました。
(本来ならここも「利用可能」になる)
この状態でEC2からAmazon File Cacheへマウントしてみると、
# Amazon File Cache は /mnt/cache/ にマウントしてみる
sudo mkdir /mnt/cache/
# マウント処理を実行
sudo mount -t lustre -o relatime,flock fc-07aexxxxxxxxxxxxx.fsx.ap-northeast-1.amazonaws.com@tcp:/ixxxxxxx /mnt/cache
mount
コマンド自体は成功するのですが、マウント先では何一つデータが表示されない状態となりました。
データリポジトリの関連付けが完了してくれないとダメな感じです。
# mountコマンドは成功するも...
$ sudo mount -t lustre -o relatime,flock fc-07aexxxxxxxxxxxxx.fsx.ap-northeast-1.amazonaws.com@tcp:/ixxxxxxx /mnt/cache
# マウント先では何も表示されず
$ ls /mnt/cache/
# Amazon File Cacheへの接続自体はできている
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 7941576 2341224 5583968 30% /
tmpfs 494692 0 494692 0% /dev/shm
tmpfs 197880 836 197044 1% /run
tmpfs 5120 0 5120 0% /run/lock
/dev/xvda15 106858 5329 101529 5% /boot/efi
tmpfs 98936 4 98932 1% /run/user/1000
10.0.21.149@tcp:/ixxxxxxx 1201383168 10240 1201370880 1% /mnt/cache
で、このまま約1時間待ったのですが状態が一切変わらなかったのでキャッシュを削除しました。
ホスト名指定が悪かったのかと思い、EFSのセキュリティグループを全開放の上、マウント先のパスをIPアドレス指定[1]にしてリトライしたものの結果は変わらずでした。
(EFSへの接続をIPアドレス直接指定にしても結果は変わらず)
さらにEFSと同じサブネットに別途Amazon Linux 2のEC2を用意しNFSサーバー(NFS v3, NFS v4)にしてAmazon File Cache環境を作ってみたところ、こちらはあっさり正常に動作しました。
(EC2 10.0.21.250
に別途NFSサーバーを構築しキャッシュ元に設定)
(EC2 NFSサーバーの場合はあっさり正常に動作)
結果判定
ここまでの結果から、残念ながらEFSはAmazon File Cacheのサポート外だと考えられます。
おそらくですがAmazon File CacheはNFS v3でしか通信できないのでしょう。
補足 : EC2 NFS設定
EC2 NFSサーバーの構築はざっくりこんな感じでやってます。
AMIは本日時点で最新のものを使用しています。
# nfs-utilsははじめからインストール済み
# NFS用ディレクトリ作成
sudo mkdir /nfshare
sudo chmod 777 /nfshare
# exportsファイル作成、設定の反映
echo "/nfshare *(rw,root_squash)" | sudo tee -a /etc/exports.d/export-nfs.exports
sudo exportfs -ar
sudo exportfs -v
# NFSサーバーを開始
sudo systemctl start nfs-server
# 状態の確認
systemctl status nfs-server
最後に
以上となります。
結果としてはこんな感じでしたが、私の考慮が足りない部分があるかもしれないので念のためAWSサポートにも問い合わせておこう[2]と思います。